Если вы решили удалить снапшоты виртуальной машины VMware vSphere, а во время этого процесс завис на 95%:

Нужно сделать следующие вещи:

1. Соединиться с хостом ESX по SSH
2. Выполнить команду service mgmt-vmware restart для перезапуска служб управления
3. Перезагрузите хост ESX
4. Открыть snapshot manager и создать новый snapshot
5. Удалить все снапшоты (delete all snapshots)
6. Включить виртуальную машину

Как вы знаете, из GUI vSphere Client есть способ массового обновления VMware Tools в виртуальных машинах. Но бывает так, что установка VMware Tools зависает и почему-то не может быть отменена через клиент.

В этом случае динамическая миграция vMotion для виртуальной машины недоступна. Вы получите вот такое сообщение:

The virtual machine is installing VMware Tools and cannot initiate a migration operation.

Что нужно делать, чтобы отменить установку VMware Tools:

1. Заходим в сервисную консоль ESX, где запущена данная виртуальная машина и выполняем команду:

/ust/bin/vmware-cmd -l

2. Копируем путь из результатов вывода в следующую команду:

/usr/bin/vmware-cmd /vmfs/volumes/datastore-name/vm-folder/vmx-file.vmx getid

3. Используем полученный ID виртуальной машины для отмены установки VMware Tools:

/usr/bin/vmware-vim-cmd vmsvc/tools.cancelinstall idnumber

Как многие знают, недавно компания VMware выпустила обновление продукта VMware vSphere 4.0 Update 2. Среди прочих нововведений есть также улучшения механизма VMware HA для отказоустойчивости серверов VMware ESX. Одно из улучшений - решение проблемы Split Brain в кластере HA, которое заключалось в следующем:

Если у вас есть несколько хостов ESX, подключенных к IP-системе хранения iSCSI / NFS, а для виртуальных машин выставлено действие Leave Powered On для Isolation Responce (по умолчанию), то при отключении хоста от всех сетей (IP Storage и VM Network) процессы VMX, реализующие исполнение виртуальных машин оставались в памяти.

При этом, по истечении срока действия лочек VMware HA, остальные хост-серверы ESX запускали эти виртуальные машины. Когда соединение выпавшего хоста с сетью и хранилищем восстанавливалось - процессы продолжали жить, что приводило к так-называемому "пинг-понгу" виртуальных машин между хостами ESX и всяким глюкам.

Теперь же, начиная с VMware vSphere 4.0 Update 2 эта ситуация решается - хост ESX выключает виртуальную машину и генерирует соответствующее событие в vCenter.

Источник: yellow-bricks.com.

Многие пользователи сейчас уже тестируют и внедряют решение для виртуализации настольных ПК VMware View 4. Как оказалось, в некоторых случаях при соединении с десктопом под управлением Windows XP с помощью клиента VMware View Client возникает ошибка connect desktop failed:

При этом соединение с виртуальным ПК VMware View 4 по RDP работает.

Если посмотреть в Event log, то там будет вот такое сообщение:

Failed loading plugin: wswc_PCOIP.dll, error 126 (the specified module could not be found)

Если поискать эту библиотеку - ее действительно не обнаружится. Данная проблема связана с отсутствием поддержки инструкций SSE2 в процессоре ПК, где установлен VMware View Client. Читаем в документе "View Manager Administration Guide":

Client hardware requirements include the following:

• 800Mhz or higher processor speed
• x86‐based processor with SSE2 extensions

Таким образом, в этом случае вы не сможете заставить работать ваш ПК в качестве клиента VMware View 4 по протоколу PCoIP. Поэтому необходимо предварительно посмотреть VMware Compatibility Guide на соответствие вашего устройства требованиям VMware View. Чтобы проверить наличие функций SSE2 в процессоре вашего ПК, воспользуйтесь утилитой CPU-Z:

Коллега Vladan Seget опубликовал полезную заметку про ошибку при установке VMware Workstation 7. Если у вас появляется вот такая ошибка:

Error 1327. Invalid drive x:

Это значит у вас есть сетевые диски (Network Drives), либо папка My Documents перемаппирована на сетевую шару. Продолжить установку VMware Workstation 7 без ошибки можно, просто отключив сетевые диски в Explorer.

С папкой мои документы все чуть сложнее. В ключе реестра Personal в ветке:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders нужно сменить путь к сетевой папке на дефолтный путь: %USERPROFILE%\Documents (после установки можно поменять назад).

Данные действия также описаны в KB 1006536.

Если вы используете продукты для резервного копирования виртуальных машин на серверах VMware ESX (например, Veeam Backup), то можете столкнуться с проблемой, когда появляется вот такая ошибка:

Disk "Hard disk 1" has incorrect changed block tracking configuration.

Эта ошибка связана с некорректной конфигурацией технологии Change Block Tracking (отслеживание изменившихся блоков виртуального диска) для витуальной машины. Vladan Seget подсказывает, как эту проблему решить. Открываете VMware vSphere Client, выбираете нужную виртуальную машину на ESX и нажимаете Edit Settings > вкладка Options  > категория General, выбираете Configuration Parameters и выставляете все записи, содержащие часть строки ctkEnabled, в значение false. Вот так, как на этой картинке:

После этого Veeam Backup автоматически включит технологию Change Block Tracking для виртуального диска машины с корректными настройками при запуске следующей задачи. Напоминаю, что Veeam Backup - это лучшее средство резервного копирования виртуальных машин для VMware vSphere / ESX.

Как уже сообщалось, компания VMware выпустила Update 1 для виртуальной инфраструктуры VMware vSphere 4.0 в части хостов VMware ESX и сервера VMware vCenter. Обновить хост-серверы ESX можно с помощью продукта VMware Update Manager, однако это чревато негативными последствиями, описанными в KB 1016070.

Проблема касается хост-серверов ESX с установленными сторонними агентами производителей оборудования и описывается следующими симптомами:

1. VMware Update Manager прекращает обновление на ESX 4 Update 1 и останавливается на 33%.
2. После перезагрузки VMware ESX выпадает в purple screen с сообщением:

COS Panic: Int3 @ mp_register_ioapic

Проблема в том, что после перезагрузки хоста VMware ESX 4 с неудачным обновлением Update 1, вам придется переустанавливать ESX, что приведет к потере виртуальных машин на локальных datastores. Чтобы этого не произошло, необходимо отключить все сторонние агенты на ESX перед обновлением до Update 1. Если вы уже обновились, но не перезагружали хост - обратитесь в техническую поддержку VMware.

Великий Duncan поднял очередную болезненную тему для VMware vSphere. У них (VMware) есть заказчик, у которого 5 хостов VMware ESX в кластере VMware DRS. Вечером, когда нагрузка на хосты ESX спадает, 4 из них переходят в standby режим (делает это механизм Distributed Power Management), остается один хост на котором сервер vCenter, работающий в виртуальной машине.

Если этот единственный хост VMware ESX погибает - вся инфраструктура остается выключенной, поскольку некому вывести остальные хосты из standby и перезапустить vCenter. Все это потому, что Admission Control в настройках кластера VMware HA выключен и отказоустойчивость кластера не гарантирована. То есть это не баг - а фича. Но...

Бывает такая ситуация, что обновление VMware Tools виртуальной машины с ОС Windows на ESX проходит неудачно вследствие невозможности удалить предыдущую версию. При удалении VMware Tools вручную возникает ошибка и получаются такие сообщения:

Как же все-таки удалить VMware Tools? Очень просто - открываем редактор реестра (команда regedit) и открываем ветку:

HKLM\Software\Microsoft\Windows\CurrentVersion\uninstall

и ищем в ней ветку, которая содержит ключ...

Как вы понимаете, без багов в только вышедшей мажорной версии не обходится ни один продукт. Особенно такой навороченный как VMware ESX 4 из состава vSphere. Сегодня опишем еще одну багу ESX 4, проявляющуюся как невозможность приконнектиться с VMware ESX 4 из vSphere Client в течение некоторого времени после установки хоста ESX или его загрузки. В клиенте выдается ошибка 503 Service Unavailable. Проблема проявляется как при чистой установке VMware ESX 4, так и при обновлении с ESX 3. Баг явно связан с отключенным по умолчанию VMware Web Access на ESX 4.

Коллеги, после VMotion виртуальной машины на другой хост VMware ESX в vSphere я получил вот такое состояние работающей виртуальной машины, у которой справа от имени отображался статус Invalid. Кнопки выключения и редактирования свойств само собой загреены. Виртуальная машина продолжает прекрасно работать:

После недолгих изысканий была найдена статья KB "A virtual machine does not power on and displays in VMware Infrastructure Client as Invalid". Парадокс в том, что такое произошло с работающей виртуальной машиной на ESX, а KB про остановленную, которая при запуске выдает сообщение "A general system error occured: Not initialized". Эта ошибка говорит о том, что vmx-файл конфигурации виртуальной машины поврежден.

Итак, что нужно сделать, чтобы исправить статус Invalid у виртуальной машины:

Компания VMware вместе с vSphere / ESX 4 выпустила продукт VMware Data Recovery 1.0 для резервного копирования виртуальных машин. Как оказалось, в Data Recovery первой версии оказался один очень серьезный баг: снапшоты, сделанные механизмом VMware Dtata Recovery, не удалялись после снятия резервной копии.

Суть бага проста - в файл-дескриптор снапшота (vm_name-000001.vmdk) виртуальной машины добавлялась и не удалялась строчка ddb.deletable = "false", которая не позволяла после отработки механизма VMware Data Recovery удалить снапшот. В результате для виртуальных машин снапшоты множились и росли, очень сильно изменяя инфраструктуру в очень плохую сторону, тем более, что утилиты типа RVTools не могли их обнаружить.

Для решения проблемы предлагается использовать скрипт...
Таги: VMware, vSphere, Data Recovery, Bugs, ESX, vmdk

USB устройства в виртуальных машинах на ESX в VMware vSphere.

На 164 странице документа VMware vSphere Basic System Administration можно найти информацию о добавлении USB-контроллера виртуальной машине на ESX:

Однако, очень уважаемые коллеги из компании Xtravirt утверждают что проброс USB устройств в виртуальную машину на VMware ESX сегодня не работает ...
Таги: VMware, vSphere, USB, ESX, Bugs

Исправлена ошибка в VMware ESX Update 3 (неактивны пути к SAN LUN и ВМ отваливаются от vmdk).

Компания VMware выпустила обновление для ESX Update 3, исправляющее ошибку пропадания доступа виртуальных машин к виртуальным дискам vmdk. Ошибка проявлялась в том, что при настроенном множественном доступе (Multipathing) к SAN LUN, могла произойти ситуация когда все пути к LUN становились неактивными, а виртуальные машины, соответственно, теряли доступ к своим vmdk...
Таги: VMware, ESX, Bugs, Storage

Баг в VMware ESX 3.5 Update 3 – хосты отваливаются от VirtualCenter и неактивны пути к LUN.

В базе знаний VMware (KB1008130) появилась информация о странностях в поведении хостов VMware ESX 3.5 Update 3 при обновлении метаданных томов VMFS. Могут происходить следующие вещи...
Таги: VMware, ESX, ESXi, VirtualCenter, vCenter, Bugs

Hyper-V подвергает риску приложения в виртуальных машинах при миграции (Quick Migration), а VMware VMotion - нет.

Как известно, возможности «быстрой» миграции гипервизора Hyper-V значительно уступают функциональности VMware VMotion. В очередной раз инженерами VMware было продемонстрировано как именно Hyper-V может аффектить приложения в виртуальной машине при миграции.

Суть опыта была такова: было 2 хоста Hyper-V, один с поддержкой инструкций SSE 4.1, другой - без. Виртуальную машину с запущенным Adobe Premier мигрировали между хостами Hyper-V. В результате, после миграции приложение «выполнило недопустимую операцию и было закрыто». После этого попробовали сделать VMotion – VMware ESX не позволил смигрировать виртуальную машину, сославшись на несовместимость процессоров.

Смотреть видео VMware...
Таги: VMware, VMotion, Hyper-V, Bugs

Оопс - снова баг у VMware: RCLI в режиме чтение-запись для ESXi.

В этом посте VM Guru была опубликована информация о том, что доступ к конфигурации VMware ESXi через Remote Command Line Interface (RCLI) стал в режиме «чтение-запись». Оказалось это не фича а баг. Ошибка была допущена программистами при отладке VI API. По информации западных коллег, в ближайших обновлениях она будет исправлена.

Этот баг продолжает печальную серию из таких серьезных ошибок, как...
Таги: VMware, ESX, ESXi, Bugs

Ошибка лицензирования в VMware VI 3.5 Update 2 - A general system error occurred: Internal Error